Collaboration framework

ABSTRACT

One or more embodiments of the invention provide a collaboration framework for collaborating access to a drawing document on a network. A drawing document is stored on a server. Thereafter, a collaboration session comprised of two or more collaborators on a network is established. During the collaboration session, the server permits the two or more collaborators to work simultaneously across the network on the drawing document stored on the server. A command to modify the drawing document from a first collaborator is received by the server. The server then distributes the command to modify the drawing document to other collaborators in the session.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is related to the following co-pending andcommonly-assigned patent applications, which applications ateincorporated by reference herein:

[0002] Patent Cooperation Treaty Patent Application Serial No. PCT/US01/02310, entitled “METHOD AND APPARATUS FOR PROVIDING ACCESS TO ANDWORKING WITH ARCHITECTURAL DRAWINGS ON THE INTERNET”, by Douglas G.Look, et. al., Attorney Docket No. 30566.101-WO-U1, filed on Jan. 24,2001, which application claims priority to United States ProvisionalPatent Application Serial No. 60/177,988, entitled “METHOD AND APPARATUSFOR PROVIDING ACCESS TO AND WORKING WITH ARCHITECTURAL DRAWINGS ON THEINTERNET,” filed on Jan. 25, 2000, by Douglas G. Look, et. al.,attorney's docket number 30566.101USP1.

BACKGROUND OF THE INVENTION

[0003] 1. Field of the Invention

[0004] The present invention relates generally to computer-implementeddrawing programs, and in particular, to a method, apparatus, and articleof manufacture for multiple collaborators to simultaneously work on adrawing.

[0005] 2. Description of the Related Art

[0006] The use of Computer Aided Design (CAD) application programs iswell known in the art. CAD application programs are often expensive,complex, and difficult to learn how to use. Additionally, architects,contractors, engineers, owners, and other patties involved with aproject (referred to as project participants or collaborators) are oftenmobile or at different locations. With new technology and the increaseduse of the Internet, project participants often have computers, Internetaccess, and personal digital assistants (PDAs). Further, thecoordination and exchange of information between project participantscan be increasingly complex.

[0007] Existing prior art applications allow a user to download adrawing, edit the drawing, and upload the drawing after completing theedits. Alternatively, prior art applications/features may allow thecreation of a two-dimensional in-memory document where graphicinformation is transmitted from one client to another client during asession. However, in such prior art applications, to refer to a documentin the future (i.e., to store the document), the document must be savedlocally by a client and then uploaded later. Further, since only anin-memory document is used, there is no capability to undo amodification or to restore the document in the event of a network orcomputer failure. Further, only a primitive set of two-dimensionalgraphic manipulation tools is often provided.

[0008] Accordingly, existing prior art applications do not provide theability for multiple users to collaborate on an actual stored documentwith a full set of modeling tools (in two and three dimensions).

SUMMARY OF THE INVENTION

[0009] One or more embodiments of the invention provide a method,apparatus, and article of manufacture for a collaboration framework thatpermits multiple users to simultaneously modify a document/workspacethat is stored on a server across a network. Collaboration applicationson multiple clients/collaborators communicate with a server applicationon a server.

[0010] The collaboration application provides a full set ofthree-dimensional drawing tools to manipulate a drawing and transmitsuch manipulations to the server application. The server applicationmaintains a history of the manipulations and the collaborators in asession. Once a manipulation command is received by the serverapplication from one collaborator, the server distributes the command tothe remaining collaborators. Thereafter, the collaboration applicationsmodify the local version of the drawing space in accordance with thecommand. The history maintained by the server may then be used by anyone of the collaborators to rollback a modification (e.g., amodification made by another collaborator or themselves) or to rebuild adrawing space in the event of a network failure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Referring now to the drawings in which like reference numbersrepresent corresponding parts throughout:

[0012]FIG. 1 schematically illustrates a hardware and softwareenvironment in accordance with one or more embodiments of the invention;

[0013]FIG. 2 illustrates a collaboration palette displayed in accordancewith one or more embodiments of the invention;

[0014]FIG. 3 illustrates a dialog window and collaboration palette inaccordance with one or more embodiments of the invention; and

[0015]FIG. 4 is a flow chart illustrating the use of the collaborationframework in accordance with one or more embodiments of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] In the following description, reference is made to theaccompanying drawings which form a part hereof, and which is shown, byway of illustration, several embodiments of the present invention. It isunderstood that other embodiments may be utilized and structural changesmay be made without departing from the scope of the present invention.

[0017] Overview

[0018] A collaboration framework provides the ability for multiple usersto simultaneously modify a document across a network using a full set oftools. Client based applications generate specific messages (e.g., XMLmessages) which are communicated across a network to a server (e.g., viaTCP/IP [transmission control protocol/internet protocol]). Once receivedby the server, the server manages the collaboration session by storingdocument changes and distributing the command to other collaborators.The server maintains a history of document changes so these can berecommunicated in the event of a network failure or temporary Internetoutage. Additionally, the server may manage a record of thecollaboration session including the name, number and status ofcollaborators, and similar information for the workspace beingcollaborated on.

[0019] Hardware Environment

[0020]FIG. 1 schematically illustrates a hardware and softwareenvironment in accordance with one or mote embodiments of the invention,and more particularly, illustrates a typical distributed computer system100 using a network 102 to connect client computers/collaborators 104 toserver computers 106. A typical combination of resources may include anetwork 102 comprising the Internet, LANs (local area networks), WANs(wide area networks), or the like, clients/collaborators 104 that arepersonal computers, personal digital assistants (PDAs), or workstations,and servers 106 that are personal computers, workstations,minicomputers, or mainframes.

[0021] In accordance with one or more embodiments of the invention, thenetwork 102 connects collaborators 104 executing a collaborationapplication 108 to server computers 106 executing server applications110. The collaboration application 108 enables collaborators 104 tocommunicate with other collaborators 104 and work on a document storedon/by server 106. The server application 110 may be a server 106collaboration application that provides for storage of a commonly useddocument and enables the ability for multiple collaborators 104 tosimultaneously work on the same document. Server application 110 mayalso be configured to manipulate data (e.g., a document) in database 114through a database management system (OBMS) 112.

[0022] Generally, these components 108, 110, 112, and 114 all compriselogic and/or data that is embodied in or retrievable from device,medium, signal, or carrier, e.g., a data storage device, a datacommunications device, a remote computer or device coupled to thecomputer across a network or via another data communications device,etc. Moreover, this logic and/or data, when read, executed, and/orinterpreted, results in the steps necessary to implement and/or use thepresent invention being performed.

[0023] Thus, embodiments of the invention may be implemented as amethod, apparatus, or article of manufacture using standard programmingand/or engineering techniques to produce software, firmware, hardware,or any combination thereof. The term “article of manufacture” (oralternatively, “computer program product”) as used herein is intended toencompass logic and/or data accessible from any computer-readabledevice, carrier, or media.

[0024] Those skilled in the art will recognize many modifications may bemade to this exemplary environment without departing from the scope ofthe present invention. For example, those skilled in the art willrecognize that any combination of the above components, or any number ofdifferent components, including different logic, data, differentperipherals, and different devices, may be used to implement the presentinvention, so long as similar functions are performed thereby.

[0025] Collaboration Framework

[0026] Collaboration application 108 and server application 110executing on client 104 and server 106 respectively, provide acollaboration framework that enables modifications to drawings to beshared in real time among a set of collaborators 104 (i.e., two or moreusers working simultaneously on the same document from differentcomputers or other network 102 devices).

[0027] The collaboration framework provides the ability for allcollaborators 104 to modify a document at the same time, with no needfor permission to modify to be passed around among the collaborators104. Once a collaborator 104 has joined a session, the collaborator 104is likely on equal footing with all other collaborators 104. Thus, bydefault, anyone may join a collaboration session and begin collaboratingwith others that may already be working in the session. Alternatively,while multiple collaborators 104 may edit the document, anothercollaborator 104 may not have write access and may only have readcapability to watch the modifications of other collaborators 104.

[0028] Collaboration Process

[0029] The initial user in a collaboration session opens a workspace ordocument to work on. Once opened, a collaboration palette may bedisplayed on the computer 104 by collaboration application 108. Forexample, the palette may be placed in the lower-right corner of thewindow representing collaboration application 108. Alternatively, whennot in use, the palette may roll-up or be hidden from the user.

[0030] The collaboration palette provides information on the currentcollaborators/users 104 in the collaboration session. Thus, when adocument is opened by a user, the user's name is added to thecollaboration palette. Further, an access level may be assigned to theuser. For example, a user's access level may default to “write-access”.Beyond this general information, the palette may not open or show anyadditional feedback when the initial user opens a workspace.

[0031]FIG. 2 illustrates a collaboration palette displayed in accordancewith one or more embodiments of the invention. As illustrated, elementsof the collaboration palette 200 may include a user image/icon 202. Theicon 202 used for the user may be a standard 32×32 GIF (graphic imageformat) for all users.

[0032] In addition, the top line 204 of a data area of palette 200 maycontain the user's name. Further, the second line 206 of the data areamay contain the user's status. Each status type 206 may have anassociated color. For example, the status types 206 and colors a usermay have are joining (green), write-access (black), accidentaldisconnect (red), intentional disconnect (yellow), and working offline(blue). In order to show a status change, all of the status labels,except “joining,” may blink then disappear after a short duration. Thejoining status may remain until the user either connects or cannotconnect to the workspace.

[0033] A user's status 206 may also reflect a controlled environmentwherein a single user may be a moderator that has the ability to grantor deny access to new and existing users. FIG. 3 illustrates a dialogwindow in such a controlled environment. As illustrated, the statusfield 206 may identify the first user as a moderator. Further, when anew user attempts to join a session, the status field 206 may display amessage such as “request write” to indicate that a user is requestingwrite access. Additionally, a dialog window 302 may be presented to themoderator that allows the moderator to grant or deny the new userpermission to join the workspace as a collaborator 104. Advanced optionsmay also be available such as allowing a user to join the session butwith read-only capability.

[0034] A scroll bar may be activated on the palette if necessary todisplay additional information. Further, a palette titlebar 208 includesthe title of the palette 200 and may flash for a short duration when thestatus of any collaborator 104 changes. The color the titlebar 208flashes may depend on the new status of the collaborator.

[0035] When a second user opens a document or workspace, the workspaceopens as usual on the user's computer 104, along with opening thecollaboration palette 200 to signal the beginning of a collaborationsession. However, the collaboration palette 200 automatically indicatesthat another user has the workspace open already.

[0036] The palette 200 also provides a mechanism for displaying thestatus 206 of the second user's connection to the workspace. Wheninitially opened, the second user's status 206 likely reads “joining.”When the second user successfully joins the collaboration session, thestatus line 206 changes to “write-access.” Thereafter, if current usersof the workspace have closed the collaboration palette 200, the titlebar208 may flash to signify the addition of a user to the workspace.

[0037] As the workspace is being opened for a second user, a “glassplane” may be placed over the workspace, palettes 200, and menu.Further, in some embodiments, a user may not be able to cancel the open,or start to open another workspace until the current one is fullyopened. As illustrated in FIG. 2, the palette 200 indicates that a firstuser (i.e., “Joe User”) has write-access and a second user (i.e., “User#2”) is joining the session.

[0038] Accordingly, as users join the session, each user's collaborationpalette 200 indicates the addition of a user, with a status 206 of“joining.” When a user leaves the workspace on purpose, the user'sstatus 206 (e.g., “left workspace”) may be shown in a specific color(e.g., yellow), and after some amount of time, the user's name 204 willbe removed from the palette 200. Similarly, if a user leaves theworkspace accidentally, the user's status 206 (e.g., “disconnected”) maybe shown in a different color (e.g., red), and after some amount oftime, the user's name 204 will be removed from the palette 200.

[0039] Once a session has begun, modifications to the drawing may beseen by any users in the session. For example, a pan or zoom operationperformed on the workspace by a user will be reflected in other users'view of the workspace. Accordingly, the pan and zoom state of theworkspace may be stored with the document. Thereafter, the next time theworkspace is opened, the view will be the same as when it was lastclosed. Similarly, if the view of a 3D model is changed by a user, theother users' view of the model will be changed. Additionally, any actionthat causes data to be saved to the workspace will be seen by all of theusers in the collaboration session. For example, creating new documents,moving documents, minimizing documents, and using tools on documents,are all actions that will be seen by everyone.

[0040] Additionally, the collaboration framework may providecommunication capabilities such as chat and instant messaging tocollaborators 104 in the session.

[0041] However, to preserve individual user's preferences, certainactions performed by a user may not be seen by other users in thesession. For example, a user's palette 200 may not be part of thecollaboration session. Thus, if a user moves his or her palette 200 ordrawing tools from the upper left to the lower right, the collaborators104 will not see a change in their view of the workspace. Further, anyobject selected by a collaborator 104 may not be seen in the othercollaborator's 104 view of the workspace. However, any action done tothe object that changes its data (e.g., color or size change) will beseen by the other users. Additionally, the activation of documents maynot be seen by collaboration users. For example, if a user has “Drawing1” active, and is actively placing strokes into it (which is seen by theother users), he or she will not see that another user may have a modeldocument active. However, if the second user begins to rotate the modelin the document, the result will be seen by all of the collaborators104.

[0042] The loss of a network 102 connection by a user affects the waythe user continues. When a single user of a workspace (i.e., no othercollaborators 104 are members of the session) loses his or her network102 connection, the user may be automatically switched to an offlinemode during which the user may keep write-access while offline, and theserver 106 marks the workspace as offline so it may not be edited byonline users. When a user in a collaborative environment loses aconnection, the remaining users will be notified that the user hastimed-out with the disconnected status in the data field 106 of thepalette. The disconnected user may also receive a dialog notice that theconnection to the workspace has been lost, and the user has thereforebeen switched to read-only mode.

[0043] Colaboration Details

[0044] As described above, collaborators 104 participating in a sessionmay all modify a drawing document that is stored in the server 106wherein the drawing modifications are then reflected in the othercollaborators' 104 views. To enable such capabilities, the collaborationframework provides for the transmission of commands to the client 104and server 106 sides of the framework. The description below providesinformation regarding some of the commands that may be used includingbackground information, implementation information, and formattinginformation, It should be noted that while the formatting information isdescribed in terms of extensible markup language (XML), any acceptableformat or formatting language may be used and the invention is notintended to be limited to XML formatted messages.

[0045] There are two types of command communication between clients 104and server 106 in the framework 100: synchronous and asynchronous.

[0046] Synchronous commands are sent from the client 104 to the server106, and processed immediately. The server's 106 response is a commandresponse containing the processing results.

[0047] Asynchronous commands ate sent from the client 104 to the server106, but are not necessarily processed immediately. The server 106response to the client 104 may contain multiple command responses toearlier client 104 requests, collaboration state changes, collaborationuser information, and other data waiting in the client's 104 outgoingmessage queue. As described below, a command referred to herein as“heartbeat” is an example of such an asynchronous command.

[0048] While strictly speaking, there may only be a single command type,there are three distinct types of command messages: Commands, Responses,and Heartbeats.

[0049] Commands initiate a request or an action. Commands may typicallycontain one or more <param\> sub-nodes. Usually, commands are a requestfrom the client 104 to the server 106 to initiate an action or requestdata.

[0050] Responses are commands containing processing results and returndata from previously issued commands. There is typically a one to onecorrespondence for a response to a specific command. For example, a“Version” command likely has a corresponding “Version” response commandwhich is returned to the client 104 and contains data pertaining to thecurrent version of the framework. Responses typically contain a<success\> sub-node, a <rspMsg\> sub-node, and one or more <return\>sub-nodes.

[0051] Heartbeats are asynchronous commands that can contain othercommands, responses, or collaboration data.

[0052] As described above, messages may be implemented in any format. Inone or more embodiments of the invention, messages are simple XMLstructures. Using a login command message from the client 104 as anexample, the basic structure is shown below: <msg msgID=“1” sessID=“1”resID=“23058” retry=“0”> <cmd name=“Login”> <param name=“username”val=“joe smith” /> <param name=“password” val=“JoesPswd” /> </cmd></msg>

[0053] The outermost node, <msg\>, wraps the entire message. A messagetag may be required to contain the following attributes in Table 1.TABLE 1 Attribute Name Values Meaning MsgID Any positive integer. Client104 generated numeric identifier of the message. When the message issent from the server 106 to the client 104, the server 106 echoes themsgID number it is responding to. This pairs the client 104 request andserver 106 response message with the same ID. SessID A valid session ID.the sessionID. ResID A valid resource ID. the resourceID. Retry Apositive integer, or zero. number of times client has sent this message.

[0054] The first and only sub-node, <cmd\>, contains a single command.This single command may be a heartbeat command, which itself may containsub-commands. The command node may contain multiple attributes includinga name that specifies a unique command name for the command being sent.

[0055] Additionally, each <cmd\> node may contain one or more of the subnodes described in Table 2, depending on it's type: TABLE 2 Sub NodeName Contains Attributes Param A parameter for the Name - the parametername. command. Val - the parameter's value. Filedata An XML file of anon- NONE. specific type. Currently used for user data, workspace filesand Workspace Trees. Success Found only in response Val - return value.The constant names and values: commands, this contains aRESPONSE_SUCCESS = 0 × 0 flag indicating whether theRESPONSE_LOGIN_REQUIRED = 0 × 1 command was executed RESPONSE_FAILURE =0 × 2 successfully. If it was not, RESPONSE_RESOURCE_NOT_FOUND = 0 × 3the attribute contains a RESPONSE_INSUFFICIENT_PERMISSION = 0 × 4constant indicating the nature RESPONSE_DUPLICATE_NAME = 0 × 5 of thefailure. RESPONSE_BAD_TOKEN = 0 × 6 RESPONSE_UNKNOWN_FILETYPE = 0 × 7RESPONSE_SYSTEM_FAILURE = 0 × 80 Return Found only in response Name -the return parameter's name. commands, this contains Val - the value ofthe return parameter. return values for the previous commands. There maybe more than one return node per response message. RspMsg Found only inresponse Val - the text of the response message. commands, this containstext corresponding to the result. It may be used for providing errordescription text to be displayed to the user, for example.

[0056] Accordingly, for each command, whether issued by a client 104 ora server 106, the command name is specified along with optionalparameters. The following XML illustrates an example of a versioncommand in accordance with one or more embodiments of the invention:<!-- Client request command --> <cmd name=“Version”> <param name=“major”val=“1” /> <param name=“minor” val=“1” /> <param name=“revision” val=“2”/> </cmd> <!-- Server response command --> <cmd name=“VersionResp”><success val=“1” /> <rspMsg val=“a resp mesage” /> <returnname=“VersionResp”> <param name=“major” val=“1” /> <param name=“minor”val=“1” /> <param name=“revision” val=“1” /> </return> </cmd>

[0057] As illustrated, the client 104 request command name is “Version”and various parameters are specified. In response, the server 106specifies the command name along with information described in Table 2(i.e., a success with a value of 1, a response message with a value of“a resp message”, a return name with a value of “VersionResp”, andvarious parameters with values).

[0058] Synchronous Commands: Client Sent, Server Processed

[0059] Various synchronous commands may be processed in the framework100 of the invention. The synchronous commands described below arecommands sent by a client 104 and processed by a server 106.

[0060] Version Command

[0061] The “version” command results in a return of the current versionnumber of the framework. The syntax for the command is: version(localmajor, localminor, localrevision : major,    minor, revision,upgradeFlag, ChangesXML : success,    message )

[0062] The “version” command is sent by the client 104 at startup,before attempting a login or displaying the main application window.Even if the client 104 has a stored session id, it should issue thiscommand first.

[0063] The upgradeFlag indicates the result of the version check and canbe VersionsIdentical (0), ServerUpgraded (1), ClientUpgradeAvailable(2), ClientUpgradeRequired (4). If the upgradeFlag has aVersionsIdentical value, no code in the framework 100 has been updatedsince the last time the client 104 collaboration application 108 wasrun. If the upgradeFlag has a ServerUpgraded value, the server 106 hasnew code that may affect the clients 104 perception of how the framework100 works (faster save times, fixes, etc.), but there are no client 104binary changes.

[0064] A value of ClientUpgradeAvailable means that there is a newerversion of the client 104 available, but the client 104 is not requiredto get the newer version in order to work with the current version ofthe server 106 (i.e. no file formats or interfaces have changed). Avalue of ClientUpgradeRequited means that significant changes haveoccurred in the client 104 and file formats or interfaces with theserver 106 have changed. Accordingly, the client 104 must upgrade beforethe client 104 can go online. Note that this does not necessarily meanthe client 104 is forced to upgrade immediately. Instead, the client 104may be able to work offline using the local cache until the user isready to upgrade. However, if the client 104 desires to obtain data fromthe site/server 106, the client 104 must upgrade.

[0065] Also, any new features and/or noteworthy fixes that have beenimplemented since the version of the client 104 passed in will bereturned in the ChangesXML parameters, and these changes can bedisplayed in the client 104. It may be possible to have some updates andnot require an upgrade. For example, there may have been server-onlychanges that would be nice to let the user know about (e.g., a bug fixor improved performance). The ChangesXML may be useful to users when thevalue of upgradeFlag is ClientUpgradeAvailable, since the ChangesXMLcontent is what provides the basis upon which the client 104 decides ifthe upgrade should be made (new features and fixes vs. risk assessment).Further, the ChangesXML value does not need to be overly verbose. Forexample, the ChangesXML value may comprise a short bulleted listcontaining only changes that the average user would care about, orpossibly a hyperlink pointing to a page on a web site that may beaccessed for more detailed information.

[0066] In response to the version command, an object is returned withthe current version numbers that may be read from a local versions XMLfile. Alternatively, a data cache product may be used such that theversion numbers are stored in a database 114 and read from the cache.Thereafter, collaboration application stores the returnedmajor/minor/revision numbers and ensures that the returned numbers areused in the next version command.

[0067] The versions XML file may contain all changes over time(occasionally pruned manually) and will be read by the applicationserver 110 at start time and stored globally into an efficientlysearched data structure that may be keyed by major.minor.revision. Eachone of the database 114 entries may have an upgradeFlag that will be setto one of the levels defined above. The upgradeFlag's values may bebinary to ease in the use of a bitwise OR operation. Each entry may alsocontain any number of new feature/fix nodes, and each node might specifyan attribute classifying the type (new feature vs. enhancement vs. fix,etc). When processing a version command, if the major/minor/revisionpassed in is lower than the current maximum parsed from the file, thenan update has occurred and an upgrade may be required.

[0068] The upgradeFlag is determined by a simple bitwise OR operation ofall upgradeFlags of the versions greater than the version passed in. TheChangesXML is built in a similar way, by combining all of the changenodes for the versions greater than the one passed in. If the providedversion is not found, then the version has been pruned, and the earliestversion in the data structure is used to determine the upgradeFlag andthe ChangesXML.

[0069] The version command likely executes quickly and efficiently andavoids a Denial of Service attack, since no login is required.Accordingly, the version command does not perform any database 114 readoperations, database 114 write operations, and only performs a singleremote method invocation (RMI) call.

[0070] Login Command

[0071] The login command is executed by the client 104 at startup tologon to a session. In one or more embodiments, the login command isused when the user does not have a session id, or when the userdetermines that the sessionid that the user has is invalid. Such a loginmay be required in when the server 106 requires the client 104 to logon(e.g., during the processing of a loginrequired command from the server106 [see below]). The syntax for the login command is: login( username,password : success, message, sessionID,  userID, imageURL )

[0072] In response to a login command, the server 106 returns a newsessionID and the userlD to the client 104. The same user can be loggedon multiple times and have multiple active sessionID's.

[0073] Open User Data Command

[0074] Once logged in pursuant to the login command, the client 104 willnext transmit the Open User Data command. More particularly, if theclient 104 has a cached sessionID from a previous instance, the client104 will first try this sessionID. If the prior sessionID fails, theclient 104 will receive a loginrequired command from the server 106 inresponse. The subsequent login (i.e., using the login command) providesa sessionid to be used with the Open User Data command. The Open UserData command opens specified user data for the client 104.

[0075] New Workspace Command

[0076] This command is used by a client 104 whenever the user selects anoption to create a new workspace/document. The newworkspace command isexecuted before the closeworkspace command of an open workspace (ifthere is one open) is executed. If the newworkspace command issuccessful, the resourcelD of the new workspace is returned, and theworkspace should be considered to be in a SoloPending state for thespecified user.

[0077] Copy Workspace Command

[0078] The copy workspace command is issued by the client 104 wheneverthe user selects an option to copy a workspace.

[0079] Delete Workspace Command

[0080] The delete workspace command is issued by the client 104 wheneverthe user tries to delete a workspace that the user has opened. Thedelete workspace command is executed before the closing an openworkspace. If successful, the deleted workspace will be gone and theuser will have to select a workspace to work on or create a newworkspace. The use of the delete workspace command may be restricted.For example, the delete workspace command may not execute if theworkspace is in CollabPending or Collab state. Accordingly, in order todelete a workspace, the user must be the only person in the workspace.The syntax for the delete workspace command is:

deleteworkspace(userID, resourceID:success, message)

[0081] To enable the delete workspace command, the server 106 may ensurethat the workspace is either open by nobody, or open by exactly the usertrying to delete it. The user must also have the appropriatepermissions. If all of these conditions have been complied with, thenthe delete workspace command will delete the workspace and remove theworkspace from a ResourceSession. Once deleted, the workspace cannot beopened at a later time.

[0082] Open Workspace Command

[0083] The open workspace command is the backbone of collaboration, andoccurs whenever the client 104 opens a new workspace. The command isissued by the client 104 before the closeworkspace command whenswitching workspaces. If the workspace is already open by two or moreusers (i.e., the workspace is in Collab state), then this user joins thecollaboration session. If the workspace is open by only one person(i.e., the workspace is in Solo state), then a collaboration session isstarted (CollabPending state) and both clients 104 are synchronized.Once synchronized, the state changes to Collab. If the workspace is notopen, the user (that is in SoloPending state) marks the workspace asopen.

[0084] A workspace session and user's workspace session may be in one ofthe following states: 0-Solo Pending; 1-Solo; 2-Collab Pending;3-Collab; or 4-Disconnected. When a workspace is not open, the workspacehas no state. When the workspace is opened, the workspace transitionsinto Solo Pending, as does the workspace's user.

[0085] Upon the new user's/client's 104 heartbeat, the state istransitioned from Solo Pending to Solo. If another user opens thedocument, the state is transitioned to Collab Pending. Once the originalclient 104 confirms synchronization of the document, the state istransitioned to Collab. If another user joins, the workspace remains inCollab state, but the user is in Collab Pending until the firstheartbeat is received, at which time the client 104 is transitioned intofull Collab.

[0086] If at any point enough users close the workspace such that thereis only one client 104 left, the state is transitioned into Solo Pendingfor that user and the workspace. Once this client 104 confirmssynchronization of the document and started creating deltas, the stateis transitioned into Solo for the workspace and the user. If at anytimea user is determined to have gone link dead, the user's state is changedto Disconnected. If at any time all users left in a workspace sessionare Disconnected, then the state of the document is changed toDisconnected. Once users have been disconnected for a sufficient timewithout returning, the disconnected users are removed from the session.If all users are removed from a session, the session is closed.

[0087] Close Workspace Command

[0088] The close workspace command is executed when a user closes aworkspace. If the user is closing the workspace due to opening anexisting or creating a new workspace, then the open or create commandsare executed first, and the close executing after their success. If theuser closes the application, closeworkspace is sent after the finalsave.

[0089] While processing this command, if the state is Collab then acollabuserinfo command may be placed in the CommandOut queues of theremaining workspace session users. If there is only one other workspacesession user, then the state of the workspace session may be changedfrom Collab to Solo Pending.

[0090] Get Object IDs Command

[0091] The Get Object IDs command is issued by a client 104 to obtain arange of unique Object IDs the client 104 can use when creatingapplication objects. A GetObjectIDs command with no parameters isrequesting a default number of IDs. The default should be sufficient fortypical online work, yet large enough to allow for sufficient IDs in thecase of subsequent connection failures so the client 104 can keepworking. A “quantity” parameter may be specified to request a specificquantity of Object ID's. Clients 104 can use numeric constants fortypical quantities or simply specify a number for the quantity. Thesyntax for the Get Object IDs command is: getObjectIDs( userID :success, message, Object ID    start, Object ID end )

[0092] In response to the command, the server 106 returns a range ofobject IDs that can be used by the client 104. In other words, afirst/start object ID and a last/end object ID are returned by theserver 106 for use by the client 104.

[0093] The GetObjectIDs command may or may not be utilized depending onthe implementation. For example, if the GetObjectIDs command is notutilized, the server 106 may map object IDs as using a Mapped Objectscommand described in detail below.

[0094] Synchronous Responses Server Sent, Client Processed

[0095] The commands described below are synchronous commands/responsesthat are transmitted by a server 106 and processed by a client 104.

[0096] Login Required Response

[0097] The server 106 generates the login required command wheneverprocessing a message or command and it is determined that the specifiedsessionID is missing or invalid (timed out). Upon receipt and execution,the client 104 sends a login command to the server 106 (see above).

[0098] System Failure Response

[0099] The server 106 generates the system failure response/commandwhenever an internal system failure occurs processing a message orcommand. Upon receipt of the system failure command, the client 104takes appropriate measures to retry the command it received the systemfailure response message for.

[0100] Heartbeat Commands

[0101] Heartbeat messages are different from other commands, as they maycontain sub commands and collaboration data. The heartbeat message usestwo sub-nodes to contain the different types of data. These are the<transientcmd\> node, which contains zero or more commands andresponses, and the <persistentcmd\> node, which contains actualcollaboration data, i.e., the actions performed in the client 104 by thecollaborators 104.

[0102] As an example, a heartbeat command demonstrating the fullstructure is shown below, although any individual heartbeat command mayor may not have all the components shown below the <cmd\> node. Theexample shows a heartbeat command with a single SaveUserDatasub-command, and a comment in the <persistentcmds\> section where a realmessage would have one or more client 104 collaboration commands: <cmdname=“Heartbeat” deltalevel=“45” beat=“1”  strong=“0”> <transientcmds><cmd name=“SaveUserData”> <param name=“file”  val=“woof_tools.xml”><filedata> <!-- user data file xml --> <filedata> </param> </cmd></transientcmds> <persistentcmds deltalevel=“45> <!-- clientcollaboration commands --> </persistentcmds> </cmd>

[0103] The heartbeat </cmd> node may be required to contain theattributes identified in Table 3. TABLE 3 Attribute Name Values MeaningDeltaLevel The current delta level. In solo See text. mode, this valueis determined by the client 104 and echoed by the server 106 in theresponse. In collaboration mode, these are temporary IDs when sent fromthe client 104, and actual IDs when sent from the server 106. BeatBEAT_TYPE_COLLAB = 1 A collaboration or solo beat. BEAT_TYPE_SOLO = 2Strong BEAT_STRONG = 1 The server 106 updates the client 104 lastcontacted BEAT_WEAK = 0 time on Strong beats, whether or not any otherdata is sent.

[0104] The heartbeat command is executed by the client 104 with a delaybetween heartbeats of N seconds, where N varies depending if the client104 is collaborating or not. Tentatively heartbeats may beat executeevery 10 seconds when solo and every 2 seconds when collaborating.Occasionally heartbeats will be strong. A strong heartbeat signifiesthat even if no data modification commands (referred to as deltacommands) are sent in the heartbeat, the users' workspace session shouldbe marked as active so that it does not timeout. For example, if aclient 104 does not perform any modifications or is away from thekeyboard for 20 minutes while in a collaborative session, the client 104won't be generating any data but the strong heartbeats will keep theclient's 104 workspace session alive.

[0105] The syntax for the heartbeat command is: heartbeat( userID,resourceID, deltaLevel, strongflag :    transientcmds, persistentcmds [deltalevel ] )

[0106] The heartbeat may contain either transient commands, persistentcommands (i.e., delta commands), or both. Transient commands areexecuted immediately and persistent commands are stored for asynchronousprocessing by a separate server-side process. Some transient heartbeatcommands are described below.

[0107] If the heartbeat comes from a solo user of the workspace, thenthe DeltaID's will already be present, and the specified DeltaLevel willrepresent the new DeltaLevel of the workspace. If the heartbeat comesfrom a collaborator 104, then none of the delta commands will have aDeltaID, and the server 106 is responsible for numbering them. In eithercase, the DeltaLevel of the workspace session needs to be updated. Ifthe heartbeat comes from a collaborator 104, then the heartbeat responsewill contain any delta commands that the server 106 has received thatare higher than the clients 104 specified DeltaLevel, and this willinclude new delta commands that the client 104 just sent. Accordingly,the heartbeat command enables the client 104 to receive the work done byanother client 104 during a session.

[0108] If the client 104 is collaborating, then any new ObjectID'sspecified in the delta commands will be temporary and will be marked assuch. Temporary ObjectIDs are mapped to real server-generatedObjectID's, and a persistent map is maintained for each user mapping theuser's temporary ObjectID to the real ObjectID. When collaborating, theresponse to a user's heartbeat command will contain the same persistentcommands that came up in the command, but with DeltaID's and realObjectID's set in them, so that the client 104 can update itself.

[0109] Part of the persistent commands node is the delta level that theclient 104 is currently at. In the collaborative case, there may bedelta commands that a client 104 has received from other users that havebeen given DeltaID's that this client 104 may not yet have. Therefore,the response message may contain not only the updated DeltaID's thatthis client 104 generated, but it may also contain those DeltaIDsspecified by other clients 104, all in the correct DeltaID order.

[0110] Depending on the implementation, the heartbeat processing mayutilize a beat flag for the status of a particular client 104. The beatflag is utilized to maintain the appropriate state between clients 104and to facilitate the collaboration between clients 104. Such heartbeatprocessing utilizing a beat flag is described in detail below.

[0111] Alternatively, instead of using a flag to maintain the state of aclient 104, the heartbeat processing may result in the generation ofseveral different collaboration transient commands that are sent to theclient 104. If the client's 104 state is Solo but the sessions state isCollab Pending, then the client 104 may receive a collabstart command.If the client's 104 state is Collab but the sessions state is SoloPending, then the client 104 may receive a collabstop command. If theclient's 104 state is Joining but the sessions state is Collab, then theclient 104 may receive a collabjoined command.

[0112] The user may also have other transient commands that have beenqueued up in a queue of outgoing commands for a particular user(referred to as a user's CommandOut queue) waiting for this heartbeat(for example, somebody may have joined the collaborative session, leftthe collaborative session, etc). These transient commands in theCommandOut queue ate sent from the server 106 to the client 104 in theresponse message, and marked in a record of the session as having beensent in this particular message ID.

[0113] A retry count for each message may also be maintained. Duringheartbeat processing, the retry count of the message may be checked.When the message is not a retry, message responses to all previousmessages have been received and processed by the client. Therefore, ifthere are any transient commands in the CommandOut queue which aremarked as sent in a previous message, such transient commands can beremoved from the queue.

[0114] The following transient heartbeat commands are transmitted by aclient 104 and processed by the server 106.

[0115] Save User Data

[0116] The save user data command is executed by the client 104 when asession is closed and optionally during sessions as userpreferences/options change. The save user data command may execute basedon an interval and a dirty flag. If the time interval has passed and theflag/preferences are dirty, then the preferences are saved.

[0117] The save user data command uses a user ID, filename, and filedata as parameters. The filename should be a valid system file type,otherwise the operation to store/save the data may fail. If a failureoccurs, a saveuserdatafailed command will likely be generated andreturned in the response message.

[0118] Save Workspace Command

[0119] The save workspace command is generated by any client 104 thathas a non-read-only workspace open. When solo, the client 104 isresponsible for sending up all delta commands in the persistent sectionof a heartbeat command that will update the server 106 from the previousdelta level to the new delta level specified. If any of the deltacommands are missing, the save will fail.

[0120] In collaborative mode, the detaLevel is the latestserver-approved delta level of the workspace that the client 104 isaware of. Therefore, the client 104 does not need to transmit persistentcommands to update the workspace, since the server already has the deltalevels. All clients 104 in a collaboration session may issue thesaveworkspace command. Further, saves may occur at a regular interval(e.g., every 1 minute). Accordingly, solo saveworkspace commands come uppursuant to regular heartbeat intervals (e.g., 6 heartbeats), and whencollaborating saveworkspace commands are likely issued at greaterheartbeat intervals (e.g., every 30 heartbeats).

[0121] Collaboration Start Confirmation Command

[0122] As described above, various transient collaboration commands mayor may not be utilized depending on the implementation. Thecollaboration start confirmation command may be generated by a client104 upon receiving and executing a collabstart command. The commandoccurs only when going from the solo to collaborative mode (i.e., from 1document viewer to 2). When the server 106 receives this command, theclient 104 is signaling that the client 104 has stopped generating deltacommands that have DeltaID's, and that it is now the servers 106responsibility to generate the delta commands. The collaboration startconfirmation command typically arrives in the same message as theclients 104 final solo saveworkspace. Subsequent to execution,heartbeats contain delta commands without DeltaID's, and all newObjectID's are temporary.

[0123] Once the server 106 receives the start collaboration confirmationcommand, the user or users that are in the Joining state can be migratedto the Joined state (they are issued collabjoined commands), as well asplacing collabuserinfo commands into the CommandOut queues of all usersin the workspace session for all of the users that just Joined. Theworkspace session state may also be updated from CollabPending toCollab.

[0124] Collaboration Stop Confirmation Command

[0125] The collaboration stop confirmation command is generated by aclient 104 upon receiving and executing a collabstop command from theserver 106. This command is only executed when going from thecollaborative mode to the solo mode (i.e., from 2 or more documentviewers to 1). When the server 106 receives this command, the client 104is signaling that the client 104 has started generating delta commandsthat have DeltaID's, and that it is no longer the servers' 106responsibility to generate delta commands. Subsequently, heartbeatsexecuted by the client 104 contain delta commands with client 104generated DeltaID's, and all new ObjectID's are real and not temporary.

[0126] Once the server 106 receives the collaboration stop confirmationcommand, the user or user may be migrated from the Pending Solo state tothe Solo state. Additionally, the workspace session state may be updatedfrom SoloPending to Solo.

[0127] Collaboration Joined Formation Command

[0128] The collaboration joined formation command (referred to ascollabjoinedconfirm) is generated by a client 104 upon receiving andexecuting a collabjoined command. A collabjoined command is onlyreceived when the user's state transitions from the collaborativepending state to the collaborative mode state. When the server 106receives the collaboration joined formation command, the client 104 issignaling that the client 104 has received the collabjoined command andis now generating delta commands (unnumbered).

[0129] Once the server 106 receives the collaboration joined formationcommand, the user is likely migrated from the Pending Collab state tothe Collab state.

[0130] Mopped Objects Command

[0131] Depending on the implementation, a mapped objects command may ormay not be provided. For example, if a Get Object IDs command (asdescribed above) are implemented, the Mapped Objects Command may not beutilized. As described above, the GetObjectIDs provides the client 104with a pool of valid IDs which are guaranteed unique. Accordingly, thereis no need for the server 106 to map the objects to IDs. However,without the GetObjectIDs command, such mapping may be necessary.

[0132] The purpose of the mapped objects command is so that the server106 can truncate the real-to-temp ObjectID maps for each client's 104workspace session once the client 104 has acknowledged that the realID's have been received. Accordingly, the mapped objects command mayonly be used when in a collaborative mode. Further, the command isoriginally server 106 generated and simply forwarded back up to theserver 106 by the client 104. By making a trip through the clients' 104queues, once received by the server 106, any temporary ObjectID's in thecommand are no longer in use by the client 104. Accordingly, temporaryObjectIDs may be removed from a state map of the server 106.

[0133] The removal of a temporary ObjectIDs causes object mapping to runconsiderably faster when processing commands from active clients 104 whoare generating numerous delta commands. Without the mapped objectscommand, the mapping table may continue to grow unchecked.

[0134] The execution of the mapped objects command may contain a seriesof elements, with a tempID and realID attribute/value pair. The elementsare parsed and the tempID's are placed into a string. The string maythen be transmitted to a single server 106 processor (along with theuserlD and resourceID) that can efficiently delete all of the temporaryobjects efficiently.

[0135] In addition to transient commands sent by a client 104 andprocessed by a server 106, the following transient commands aretransmitted by the server 106 and processed by a client 104.

[0136] Collaboration Start Command

[0137] The server 106 generates the collaboration start command whileprocessing a heartbeat if the heartbeat originated from a solo client104 and the state of the workspace session has been changed to PendingCollab. The collaboration start command signals that a collaborativesession is beginning so that the client 104 can begin the transitionfrom the solo state to the pending collaboration state. Once the client104 has finished this transition, die client 104 will issue acollabstartconfirm command to the server 106 as described above.

[0138] Collaboration User Information Command

[0139] The server 106 generates the collaboration user informationcommand in response to every heartbeat for a user in a collaborativesession. This command contains all of the data regarding users currentlyin the session including disconnected (link dead) users. It is theclient's 104 responsibility to compare the data structure to previouslyreceived data structures to figure out what users are new, what usersare gone, what users had state changes, what users had icon changes,etc., and then render appropriately.

[0140] Collaboration Joined Command

[0141] The server 106 generates the collaboration joined command whileprocessing a heartbeat command. If the heartbeat comes from a joiningclient 104 and the state of the workspace session is Collaborating, thenthis command is generated and returned on the heartbeat.

[0142] Collaboration Stop Command

[0143] The server 106 generates the collaboration stop command whileprocessing a heartbeat command if the specified userID is the only userleft in the workspace session. The command signals that thecollaborative mode should stop, and that the client 104 should enter thepending solo mode and signal to the server 106 that the client 104 hassent up all of the client's 104 un-numbered delta commands.

[0144] Beat Flag

[0145] The various transient collaboration commands described above(e.g., Collaboration Start Confirmation Command, Collaboration StopConfirmation Command, Collaboration joined Formation Command,Collaboration Start Command, Collaboration User Information Command,Collaboration joined Command, and Collaboration Stop Command) may not beutilized in one or more embodiments of the invention. Instead, a flagmay be used in the Heartbeat command that maintains state informationfor clients 104.

[0146] At the server 106 level, the state of the workspace itself aswell as the state of the client 104 may be considered. However, eachclient 104 only needs to keep track of their own state. The state may bedescribed using the following values: 0=closed, 1=disconnected, 2=solopending, 3=solo, 4=collab pending, and 5=collab.

[0147] Upon executing an open workspace command, the client 104 isplaced in one of two states: solo pending or collab pending. Theheartbeat command always echoes this state to the server 106. In turn,the server 106 will update the value of this flag after examining thestate of the workspace and the state of the users in the session.

[0148] An example of three clients collaborating using the various flagsare illustrated in Table 4. TABLE 4 Server Work- Command Client1 Client2Client3 space C1 C2 C3 1. Client1 exe- 2 2 2 cutes open work- space 2.Client1 3 3 3 heartbeats 3. Client2 3 4 4 3 4 executes open workspace 4.Client1 4 4 4 4 4 heartbeats 5. Client2 4 (no 4 4 4 heartbeats changes)4 6. Client1 5 4 5 5 4 heartbeats 7. Client2 5 5 5 5 5 heartbeats 8.Client3 5 5 4 5 5 5 4 executes open workspace 9. Client3 5 5 5 5 5 5 5heartbeats 10. Client2 5 0 5 5 5 0 5 executes close workspace 11.Client3 5 0 0 2 5 0 0 executes close workspace 12. Client1 2 0 0 2 2 0 0heartbeats 13. Client1 3 0 0 3 3 0 0 heartbeats

[0149] As illustrated in Table 4, the values in each row are the finalvalues after successful execution of each command indicated. The firstuser in a workspace session must confirm (e.g., by issuing a heartbeatcommand with a collab pending flag) to synchronize all deltas and starta collaboration session. The client 104 always checks the flag returnedfrom the server to determine whether it should change its current stateor not.

[0150] The command executed in Table 4 and the actions taken mayresemble the transient collaboration commands described above in thefollowing manner:

[0151] Step 3 (Client2 executes open workspace) is the equivalent of thecollab joined command (sent by the server 106).

[0152] Step 4 (Client1 heartbeats) is the equivalent of the collab startcommand (set by the server 106).

[0153] Step 6 (Client 1 heartbeats) is the equivalent of the collabstart confirm command (sent by client 104).

[0154] Step 7 (Client2 heartbeats) is the equivalent of the collabjoined confirm command (sent by client 104).

[0155] Step 12 (Client1 heartbeats) is the equivalent of the collab stopcommand (sent by server 106).

[0156] Step 13 (Client1 heartbeats) is the equivalent of the collab stopconfirm command (sent by client 104).

[0157] By using the beat flag in this manner, transient collaborationcommands are not needed between a client 104 and a server 106. Further,the beat flag provides a mechanism to maintain state information foreach client 104 in a collaboration session without the use of extraneouscommunications between the client 104 and server 106.

[0158] Save User Data Failed Command

[0159] The server 106 generates the save user data failed command whenthe processing of a saveuserdata command fails for reasons other thansystem failure (system failures are handled separately and consistentlyfor all commands/messages). For example, some causes for thesaveuserdata command failing may include invalid filename specified orinvalid userlD specified.

[0160] Save Workspace Failed Command

[0161] The server 106 generates the save workspace command when theprocessing of a saveworkspace command fails for reasons other thansystem failure. Failed commands due to system failures are handledseparately and consistently for all commands/messages. For example, someof the causes for the failure of the saveworkspace command may include:invalid userlD specified, invalid resourcelD specified, no access, andpossibly workspace not open.

[0162] Collaboration Flow

[0163] As described above, numerous commands may be used as part of thecollaboration framework to enable multiple users to simultaneouslyaccess and modify an actual document that is stored on a server 106.Further, the collaboration application 108 and server application 110enable the use of a full set of three-dimensional tools to modify adrawing while in a collaboration session.

[0164] The server 106 also maintains a history of all modifications tothe document. Using the history, a client 104 may undo any client's 104modification to a drawing document/workspace. Further, in the event of anetwork or system failure, the history can be used to rebuild/regeneratea document including all modifications on any client 104 byrecommunicating commands received from a client 104 to collaborators 104in a session. To provide such functionality, in addition to the history,the server 106 may maintain a record of the collaboration sessionincluding the name, numbers, and statuses of collaborators 104 in thesession.

[0165]FIG. 4 is a flow chart illustrating the use of the collaborationframework in accordance with one or more embodiments of the invention.At step 402, a document/workspace is stored on a server 106. At step404, a collaboration session is established. During a session, theserver 106 permits two or more collaborators 104 on a network 102 towork simultaneously across the network on the drawing document stored onthe server 106 (e.g., all of the collaborators 104 have write-access forthe drawing document during the session). A collaboration palette may bedisplayed to collaborators 104 in the session that provides informationrelating to the collaborators 104 in the session (e.g., the name of eachcollaborator 104, status of each collaborator 104, an icon for eachcollaborator 104, etc.).

[0166] At step 406, the server 106 receives a command (e.g., an XMLformatted command) to modify the drawing document from a collaborator104 in the session. Such a command may be invoked pursuant to thecollaborator's 104 use of a tool selected from a full set of drawingmodification tools. The command may identify an object in the drawingdocument that the collaborator 104 has modified.

[0167] At step 408, the server 106 distributes the command to modify thedrawing document to the other collaborators 104 in the session. Such adistribution may be pursuant to regularly transmitted commands (e.g.,heartbeat commands as described above) received from collaborators 104in the session. Further, as part of the command's distribution, anidentifier may be assigned to the command and distributed with thecommand to the collaborators 104. The client 104 then uses theidentifier to determine whether the command has already been reflectedin its display or not.

[0168] Conclusion

[0169] This concludes the description of the preferred embodiment of theinvention. The following describes some alternative embodiments foraccomplishing the present invention. For example, any type of computer,such as a mainframe, minicomputer, or personal computer, or computerconfiguration, such as a timesharing mainframe, local area network, orstandalone personal computer, could be used with the present invention.

[0170] The foregoing description of one or more embodiments of theinvention has been presented for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise form disclosed. Many modifications andvariations are possible in light of the above teaching. It is intendedthat the scope of the invention be limited not by this detaileddescription, but rather by the claims appended hereto.

What is claimed is:
 1. A method for collaborating access to a drawingdocument on a network, comprising: storing a drawing document on aserver; receiving, in the server, a request to open the drawingdocument; in response to the request, the server establishing acollaboration session, wherein during the collaboration session, theserver permits two or more collaborators to work simultaneously acrossthe network on the drawing document stored on the server; receiving, inthe server, a command to modify the drawing document from a first one ofthe collaborators in the collaboration session; and the serverdistributing the command to modify the drawing document to other ones ofthe collaborators in the collaboration session.
 2. The method of claim1, further comprising the server maintaining a history of modificationsto the drawing document.
 3. The method of claim 2, wherein the historyis used to support an undo command.
 4. The method of claim 2, whereinthe history is used to recommunicate modifications to the two or motecollaborators.
 5. The method of claim 1, further comprising the servermaintaining a record of the collaboration session including name,numbers, and statuses of the two or more collaborators.
 6. The method ofclaim 1, wherein the command comprises an extensible markup language(XML) command.
 7. The method of claim 1, wherein the two or morecollaborators all have write-access for the drawing document during thecollaboration session.
 8. The method of claim 1, wherein the command isreceived in the server from a first collaborator pursuant to a regularlytransmitted command.
 9. The method of claim 1, further comprising:generating an identifier for the command; distributing the identifierwith the command to the other collaborators in the collaborationsession.
 10. The method of claim 1, wherein the command specifies anobject identifier for an object in the drawing document that ismodified.
 11. The method of claim 1, wherein an extensible set of threedimensional modeling tools for modifying the drawing document issupported.
 12. A method for accessing a drawing document on a network,comprising: joining an existing collaboration session comprised of acollaborator on a network, wherein during the collaboration session,collaborators in the collaboration session can work simultaneouslyacross the network on a drawing document stored on a server; andtransmitting, to the server, a first command to modify the drawingdocument.
 13. The method of claim 12, further comprising receiving asecond command to modify the document from the server wherein thecommand was originally transmitted from another collaborator.
 14. Themethod of claim 12, wherein the command comprises an undo command. 15.The method of claim 12, wherein the command comprises an extensiblemarkup language (XML) command.
 16. The method of claim 12, furthercomprising displaying a collaboration palette that provides informationrelating to the collaborators in the collaboration session.
 17. Themethod of claim 12, wherein the command is transmitted pursuant to aregularly transmitted command.
 18. The method of claim 12, wherein thecommand specifies an object identifier for an object in the drawingdocument that is modified.
 19. The method of claim 12, wherein anextensible set of three dimensional modeling tools for modifying thedrawing document is supported.
 20. An system for collaborating access toa drawing document on a network comprising: (a) a server connected to anetwork and having a memory and a data storage device coupled thereto;(b) a drawing document stored on the server; and (c) a computer program,performed by the server, the computer program configured to: (i) receivea request to open the drawing document; (ii) in response to the request,establishing a collaboration session, wherein during the collaborationsession, the computer program permits two or more collaborators to worksimultaneously across the network on the drawing document; (iii) receivea command to modify the drawing document from a first one of thecollaborators in the collaboration session; and (iv) distribute thecommand to modify the drawing document to other ones of thecollaborators in the collaboration session.
 21. The system of claim 20,wherein the computer program is further configured to maintain a historyof modifications to the drawing document.
 22. The system of claim 21,wherein the history is used to support an undo command.
 23. The systemof claim 21, wherein the history is used to recommunicate modificationsto the two or more collaborators.
 24. The system of claim 20, whereinthe computer program is further configured to maintain a record of thecollaboration session including name, numbers, and statuses of the twoor more collaborators.
 25. The system of claim 20, wherein the commandcomprises an extensible markup language (XML) command.
 26. The system ofclaim 20, wherein the two or more collaborators all have write-accessfor the drawing document during the collaboration session.
 27. Thesystem of claim 20, wherein the command is received in the server from afirst collaborator pursuant to a regularly transmitted command.
 28. Thesystem of claim 20, wherein the computer program is further configuredto: generate an identifier for the command; distribute the identifierwith the command to the other collaborators in the collaborationsession.
 29. The system of claim 20, wherein the command specifies anobject identifier for an object in the drawing document that ismodified.
 30. The system of claim 20, wherein the computer programsupports an extensible set of three dimensional modeling tools formodifying the drawing document.
 31. A system for accessing a drawingdocument on a network, comprising: (a) a collaborator connected to anetwork and having a memory and a data storage device coupled thereto;and (b) a computer program, performed by the collaborator, the computerprogram configured to: (i) join an existing collaboration sessioncomprised of a collaborator on a network, wherein during thecollaboration session, collaborators in the collaboration session worksimultaneously across the network on a drawing document stored on aserver; and (ii) transmit, to the server, a first command to modify thedrawing document.
 32. The system of claim 31, the computer programfurther configured to receive a second command to modify the documentfrom the server wherein the command was originally transmitted fromanother collaborator.
 33. The system of claim 31, wherein the commandcomprises an undo command.
 34. The system of claim 31, wherein thecommand comprises an extensible markup language (XML) command.
 35. Thesystem of claim 31, further, wherein the computer program is furtherconfigured to display a collaboration palette that provides informationrelating to the collaborators in the collaboration session.
 36. Thesystem of claim 31, wherein the command is transmitted pursuant to aregularly transmitted command.
 37. The system of claim 31, wherein thecommand specifies an object identifier for an object in the drawingdocument that is modified.
 38. The system of claim 31, wherein thecomputer program supports an extensible set of three dimensionalmodeling tools for modifying the drawing document.
 39. An article ofmanufacture comprising a program storage medium readable by a computerand embodying one or more instructions executable by the computer toperform a method for collaborating access to a drawing document on anetwork, the method comprising: storing a drawing document on a server;receiving, in the server, a request to open the drawing document; inresponse to the request, the server establishing a collaborationsession, wherein during the collaboration session, the server permitstwo or more collaborators to work simultaneously across the network onthe drawing document stored on the server; receiving, in the server, acommand to modify the drawing document from a first one of thecollaborators in the collaboration session; and the server distributingthe command to modify the drawing document to other ones of thecollaborators in the collaboration session.
 40. The article ofmanufacture of claim 39, wherein the method further comprises the servermaintaining a history of modifications to the drawing document.
 41. Thearticle of manufacture of claim 40, wherein the history is used tosupport an undo command.
 42. The article of manufacture of claim 40,wherein the history is used to recommunicate modifications to the two ormore collaborators.
 43. The article of manufacture of claim 39, whereinthe method further comprises the server maintaining a record of thecollaboration session including name, numbers, and statuses of the twoor more collaborators.
 44. The article of manufacture of claim 39,wherein the command comprises an extensible markup language (XML)command.
 45. The article of manufacture of claim 39, wherein the two ormore collaborators all have write-access for the drawing document duringthe collaboration session.
 46. The article of manufacture of claim 39,wherein the command is received in the server from a first collaboratorpursuant to a regularly transmitted command.
 47. The article ofmanufacture of claim 39, wherein the method further comprises:generating an identifier for the command; distributing the identifierwith the command to the other collaborators in the collaborationsession.
 48. The article of manufacture of claim 39, wherein the commandspecifies an object identifier for an object in the drawing documentthat is modified.
 49. The article of manufacture of claim 39, whereinthe method further comprises providing an extensible set of threedimensional modeling tools for modifying the drawing document.
 50. Anarticle of manufacture comprising a program storage medium readable by acomputer and embodying one or more instructions executable by thecomputer to perform a method for accessing a drawing document on anetwork, the method comprising: joining an existing collaborationsession comprised of a collaborator on a network, wherein during thecollaboration session, collaborators in the collaboration session worksimultaneously across the network on a drawing document stored on aserver; and transmitting, to the server, a first command to modify thedrawing document.
 51. The article of manufacture of claim 50, whereinthe method further comprises receiving a second command to modify thedocument from the server wherein the command was originally transmittedfrom another collaborator.
 52. The article of manufacture of claim 50,wherein the command comprises an undo command.
 53. The article ofmanufacture of claim 50, wherein the command comprises an extensiblemarkup language (XML) command.
 54. The article of manufacture of claim50, wherein the method further comprises displaying a collaborationpalette that provides information relating to the collaborators in thecollaboration session.
 55. The article of manufacture of claim 50,wherein the command is transmitted pursuant to a regularly transmittedcommand.
 56. The article of manufacture of claim 50, wherein the commandspecifies an object identifier for an object in the drawing documentthat is modified.
 57. The article of manufacture of claim 50, whereinthe method further comprises providing an extensible set of threedimensional modeling tools for modifying the drawing document.